AppL No. 10/709,992 

Amdt. dated June 20,2008 

Reply to Office action of April 15, 2008 

REMARKS/ARGUMENTS 

Claim Rejections Under 35 U.S.C, S 103 

Claims 1-7 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
5 Ginzburg (US 20050053037 (hereinafter "Ginzburg") in view of Trainin (US 
20040120292) (hereinafter "Trainin"). Applicant respectfully traverses these 
rejections. 

Independent claim 1 recites: 
10 A method for transmitting a MAC service data unit (MSDU) in a network 

system, the MSDU having a plurality of pieces of frame data, the method 
comprising: 

receiving the pieces of frame data of the MSDU; and 

15 

converting the received pieces of frame data into a MAC protocol data unit 
(MPDU) and outputting the MPDU, wherein for at least one of the plurality of 
pieces of frame data, converting begins prior to haying received all of the 
plurality of pieces of frame data of the MSDU. 

20 

(Emphasis added.) 

The Office argues that Ginzburg teaches all the limitations of claim 1 except 
"wherein for at least one of the plurality of pieces of frame data converting begins 
25 prior to having received all of the plurality of pieces of frame data of the MSDU". 

The Office has looked to Trainin to remedy the deficiencies of Ginzburg. 
The Office argues that Trainin would show "wherein for at least one of the 
plurality of pieces of frame data converting begins prior to having received all of 
30 the plurality of pieces of frame data of the MSDU" by referring to paragraph 36 of 
Trainin and making the statement "e.g. one slot at a time". While applicant has 
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already pointed out in the reply to the last Office Action that he can not see how 
this text passage could possibly show this limitation, the current Office Action still 
brings no clarification on this issue for the applicant. It is totally unclear for the 
applicant what the Office means by "e.g. one slot at a time" in view of the text in 
5 paragraph 36 of Trainin and how this should show the limitation as asserted by the 
Office. 

Paragraph 36 of Trainin describes to send a frame only when received data 
has not been present on the air interface for a particular time interval, referred to 

10 as the Interframe Space. However, ACK should be sent without listening after a 
time interval, referred to as Short IFS (SIFS). In some cases, a device may be 
required to wait longer time periods such as a Priority IFS (PIFS) which is the 
SIFS plus one slot time. Distributed IFS (DIFS), which is the SIFS plus two slot 
times, and an Extended IFS (EIFS), which is much larger than any of the other 

15 intervals. Other waiting periods also could be implemented." The above text 

passage therefore describes the existence of waiting time periods in order to avoid 
conflicts with transmission from other stations and that the waiting time period 
can be different, for example for the more important ACK the waiting time is 
short in order to provide a high probability that the ACK reaches the addressed 

20 station. 

However, this passage does not at all relate to a converting of pieces of frame 
data of a MSDU to the receiving of these same pieces of frame data of MSDU 
such that the converting begins prior to having received all of the plurality of 

25 pieces of frame data of this same MSDU . Just in order to make sure the OflRce 
understands the claim limitation of claim 1 in a correct way. Applicant points out 
here that the claim limitation "converting the received pieces of frame data into a 
MAC protocol data unit (MPDU) and outputting the MPDU, wherein for at least 
one of the plurality of pieces of frame data, converting begins prior to having 

30 received all of the plurality of pieces of frame data of the MSDU " uses MPDU as 
well as MSDU and that these two should not be mixed up when looking at the 
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claim. 



Paragraph 36 only describes sending of ACK frames. ACK frames however 
are control response frames and therefore do not include frame data of a MSDU. 
5 Trainin (see Paragraph 3 first sentence) explicitly distinguishes between response 
frames (ACK, see Paragraph 4 last sentence) and frames sent from a source to the 
destination which are the frames transmitting the MPSU data. Moreover, 
Paragraph 36 even fails to show the converting of pieces of frame data or any 
other converting. ACK frames are not converted from MSDU data. Moreover, this 
10 passage teaches to wait a time interval (SIFS) and then send the ACK without 
listening to traffic on the air. In other cases, i.e. when no ACK is sent, the device 
listens for a period of time (IFS) and then sends the frame. However none of these 
cases show 

any kind of converting 

15 - any kind of converting frame data of a received MSDU data into 

MPDU (it is pointed out here that converting frame data of a 
received MSDU into MPDUs is only done in the transmission 
process when the received MSDU is intended to be wirelessly 
transmitted, see Ginzburg paragraph 11. When a whole MSDU is 

20 received and the MSDU data is not further transmitted wirelessly, 

the MSDU data are of course not converted into MPDUs. Ginzburg 
provides examples when an MSDU is converted into MPDUs for 
example when the wireless transmission is noisy or collisions 
occur.) 

25 - any kind of relation of the beginning of converting to previously 

receiving 



Trainin teaches that a response should be sent as quickly as possible upon 
expiration of an IFS, see Paragraph 48, line 4. This is because if another station 
30 starts transmitting, collision would occur and if the response frame is not received 
in time, retransmission may start, see Paragraph 46. For ACK response frames the 



4 



AppL No. 10/709,992 

Amdt. dated June 20,2008 

Reply to Office action of April 15, 2008 



IFS is the shortest of all IFS (SIFS = short IFS) compared to other IFS and 
distinguished from other frames ACK response frames are sent always after the 
SIFS without listening whether traffic occurred during the IFS or not. However, 
since the SIFS is short and since the response frame needs to wait for the 
5 validation and control of the PLCP Header, for the SIFS which is the shortest 

waiting time interval, the necessary validation and control processes may take too 
long so that it may be impossible to transmit the response frame immediately 
upon expiration of the IFS, see paragraph 49 and 50. It is to be noted that this is 
particular a problem of the response mechanism. It is clear therefore that 
10 Trainin's teaching is only related to response frames. 

It is also pointed out that Trainin describes the process of fragmenting similar 
to the fragmenting described in Ginzburg, see Paragraph 67. However, Trainin 
does not teach in the whole document to begin a conversion of the "entire 

15 message" into fragments at a time prior to having received the entire message. If 
Trainin would have had this teaching as asserted by the Office he would have 
stated it somewhere in the document for example in Paragraph 67 by describing 
for example that when sending the entire message in fragments the conversion of 
the entire message into fragments could start at least for one MPDU prior to 

20 having received the entire message. However, Trainin is totally silent about any 
time relation of the when ^^fragments'^ of data are included into a data frame 
and when this including into the data frame starts. Trainin's intention is only 
related to provide a quick generation of response frames for acknowledging 
the receiving of frames or transmitting a CTS as outlined above. This can be 

25 also seen from Paragraphs 51-57 which relate only to sending response frames. 
Only exemplary it is pointed to Paragraph 54 . .when an appropriate response 
frame should be issued" Paragraph 55 . .to issue a response . . Paragraph 56 

. .of the response frame, and preparing and releasing the data portion of the 
response frame. . .". Again it is pointed out, that a response does not contain 

30 MSDU data of the received frames which is acknowledged by the response. 
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The Office refers on page 6 of the Office Action to an acknowledgement with 
fragmentation which according to the Office is described in Paragraph 67 and 33 
of Trainin. Applicant carefully considered these text passages but was unable to 
find any disclosure which could possibly show the claim limitation ''converting 
5 the received pieces of fi*ame data into a MAC protocol data unit (MPDU) and 
outputting the MPDU, wherein for at least one of the plurality of pieces of frame 
data, converting begins prior to having received all of the plurality of pieces of 
frame data of the MSDU'' from Paragraphs 67 and 33. Paragraph 67 as described 
earlier shows the fragmentation of an entire message and the sending of an 

10 acknowledgement for each fragment when received at the receiver. However, it is 
to be pointed out that it is not described at what time the including of fragments in 
relation to the receiving of the entire message starts. Also Paragraph 33 brings no 
clarification. Paragraph 33 only describes fields of the PLCP header and that a 
PLCP Header Integrity Control field is used to check the integrity of the PLCP 

15 header. Therefore, applicant can not see what the Office wants to show by 

referring to Paragraphs 67 and 33 and how this would show the claim limitation. 

Overall, it becomes clear that Trainin neither explicitly or implicitly shows a 
transmission of an MSDU wherein a beginning of a conversion of the pieces of 

20 frame data into MPDUs is related to the receiving of all pieces of frame data of 
the MSDU and in particular not such that the conversion begins prior to having 
received all of the plurality of pieces of frame data of the MSDU. Trainin in fact 
describes fragments of the entire message instead of an entire message are 
included in a data frame in paragraph 67 but fails to describe any teaching at what 

25 time this including is done and in particular at what time in relation to the 

receiving of all frame data of the entire message is done. The person skilled in the 
art would have no motivation to modify the breaking of frames into fragments 
described in Paragraph 1 1 of Ginzburg since Trainin already describes the 
including of fragments in Paragraph 67 without mentioning anything on the 

30 beginning of the including. 
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In a telephone interview with the Examiner, Patent Agent Scott Margo 
(Registration Number 56,277) spoke with the examiner about the rejection of 
claim 1 . Regarding the claimed feature of "converting begins prior to having 
received all of the plurality of pieces of frame data of the MSDU\ the Examiner 
5 stated that Trainin teaches this feature in paragraphs 67, 71, and 74. However, 
despite the Examiner's insistence that these paragraphs teach the claimed feature, 
Mr. Margo and the applicant are unable to find relevant teachings in these 
paragraphs, and do not agree with the Examiner's citation of these paragraphs for 
rejecting the claimed limitation. Therefore, even after re-reading paragraphs 67, 
10 71, 74, the other paragraphs cited by the Examiner, and all other surrounding 
paragraphs of Trainin, the applicant has still not seen anything that supports the 
Examiner's rejection of Trainin teaching receiving all of the plurality of pieces of 
frame data before conversion begins. 

15 Dependent claims 2 and 3 depend from claim 1 . The rejection with regard 

to these claims should be withdrawn by virtue of the dependency. Moreover, 
these claims recite features that, when taken together with those of claim 1 , are 
not disclosed by Ginzburg and Trainin. 

20 Independent claim 4 recites: 



A network device comprising: 



25 



an I/O interface to receive a MAC service data unit (MSDU) which has a 
plurality of pieces of frame data; 



a buffer to store the pieces of frame data received by the I/O interface; and 



30 



a control circuit to control operations of the network device and to convert the 
pieces of frame data stored in the buffer into MAC protocol data units 
(MPDUs); 
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wherein the control circuit is configured to begin converting of at least one 
received piece of frame data into corresponding MPDU prior to having 
received all of the plurality of pieces of frame data of the MSDU. 

5 

(Emphasis added) 

The Office argues that similar to claim 1 a combination of Ginzburg and 
Trainin would teach the limitations of claim 4. Applicant respectfully traverses 
10 this assessment since a combination of Ginzburg and Trainin can not show all 
limitations of claim 4 for the same reasons as outlined for claim 1 . 

Independent claim 7 recites: 
A device comprising: 

15 

an interface to receive a MAC service data unit (MSDU), the MSDU comprising a 
plurality of pieces of data; 

a controller to convert the plurality of pieces of data into MAC protocol data units 

20 (MPDU), the controller being configured to begin converting at least one received 
piece of data into corresponding MPDU prior to having received all of the 
plurality of pieces of data of the MSDU. 

The Office argues that similar to claim 1 , a combination of Ginzburg and 
25 Trainin would teach the limitations of claim 7. Applicant respectfully traverses 
this assessment since a combination of Ginzburg and Trainin can not show all 
limitations of claim 7 for the same reasons as outlined for claim 1 . 

In accordance with the foregoing. Applicant respectfully requests 
30 reconsideration and withdrawal of the 35 U.S.C. § 103(a) rejections. 
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Conclusion 

In accordance with the foregoing remarks, Applicant believes that the 
pending claims are allowable and the application is in condition for allowance. 
Therefore, a Notice of Allowance is respectfully requested. If the Examiner 
5 maintains his rejections of the claims, the applicant respectfully requests that each 
of the above points of the applicant's remarks be fiilly addressed so that the record 
can be as clear as possible before an appeal is filed. Should the Examiner have 
any further issues regarding this application, the Examiner is requested to contact 
the below-indicated attomey. 

10 

Sincerely yours. 



C. jy cl^-^ ^^■■/ oate: 06/20/2008 



Winston Hsu, Patent Agent No. 41,526 
15 P.O. BOX 506, Merrifield, VA 221 16, U.S.A. 
Voice Mail: 302-729-1562 

Facsimile: 806-498-6673 
e-mail : winstonhsu(@naipo . com 



20 Note: Please leave a message in my voice mail if you need to talk to me. (The 
time in D.C. is 12 hours behind the Taiwan time, i.e. 9 AM in D.C. = 9 PM in 
Taiwan.) 



9 



